第９回 チームで翻訳をする（下）
泉谷しげるの還暦ライブに行ってきました。夜10時から朝の5時まで、還暦ということで60曲。もう若くないファン層にとっては肉体的にしんどいイベント ではありましたが、また一つ、実りの多い経験をさせてもらったなという感じです。若い方は泉谷しげるが歌手であることすらご存じないかもしれませんが、彼 は私の成長期、70年代のアンチヒーローの一人で、シャイな部分を乱暴な照れ隠しで押し通すあのスタイルは私の人格形成にもずいぶん影響しているような気 がします。私が乱暴になったということではなくて、「こんな滅茶苦茶なやり方でもＯＫなんだぜ」と言ってもらえて、楽になったというか。だから私も滅茶苦 茶な翻訳をして若い方に安心感を……違うか。
用語の統一
前回の続きです。泉谷は全然関係ありません。
チームで翻訳する場合に、まず問題になるのは用字用語の統一です。これを最初からある程度固めておかないと、あとでとりまとめの監訳者が（あるいは編集者 が）とんでもない目に遭うことになります。用字のほうは既存の用語の手引きなどでこれを使うと決めておけばなんとかなりますし、あとで変更するにしても一 括置換という手がありますが、原語と訳語で一定の対応を付けなければならない用語のほうは、放置するとどれが何に対応しているか分からなくなり、収拾がつ かなくなります。
さしあたり考えられるのは、最初に監訳者が索引を翻訳して全員に配っておくという方法ですが、これがそう単純にはいきません。第一に、適訳は索引だけ見て いても分からないということがあります。最初にざっと訳語を決めたとしても、実際に訳しているうちにやはり別の訳語（あるいは訳し方）のほうがよいと思い 直すことが多々あるのです。そういうときに、すでに作業を進めている翻訳者たちにどう伝えるのか。あるいは伝えなくてよいのか。第二に、翻訳者に依頼する 前にじっくりと索引の訳語を検討している時間などないことが多いということがあります。あとで苦労して訳語を統一する手間を考えると、最初にちょっと我慢 して必要な準備を整えるほうがトータルとしては早く済むはずなんですが、やはり現場に立つと早く翻訳に手をつけたい気持ちが起こってきます。
作成したwikiサイトの「迷いやすい一般用語」のページ。利用したサービスは@wikiです。右側にメニューカラムを置きました。また、上部に検索窓も置き、サイト内検索ができるようにしてあります。
用語集エクセル版。単純ですが、応用範囲は広いです。
そこで、多人数で並行して翻訳を進めながら、リアルタイムで訳語一覧の更新をしていき、できれば翻訳者からのフィードバックを受け取りながら訳語をさらに 練っていけないかと考えたのが、無料のメール・グループ（昔風に言うとメーリングリスト／ＭＬですね）と、無料の非公開ウェブサイトを使う方法です。分量 のある技術系の翻訳ならば翻訳メモリなどのツールを使って情報共有を図れるでしょうが、単発の本一冊のプロジェクトでは、そんなコストはかけられませんし ね。あくまで無料というところがポイントです。
最近では個人ブログ向けに無料のウェブスペースがたくさんあります。パスワードを設定してメンバー以外には非公開にできるものもあります。そのなかで、参 加者全員がページを編集できるwiki（ウィキ）タイプのものを選びました。右がそのサイトの1ページです。このサイトに「表記ガイド」「用語集」「参考 サイトへのリンク」などの資料や、進行管理表などを載せて、メンバーはいつでも参照できるようにしました。
固有名詞を中心とした用語集は非常に大きなものになるので、サイトに直接載せるのではなく、エクセルファイルにしてサイトからダウンロードする形にしまし た。これはメイン翻訳者の山崎さんが整理してくださって、最終的にバージョン40、項目数は2985まで達しました。エクセルで検索するのが面倒な人のた めに（私です）、辞書ソフトのPDIC版も作りましたが、他の方はエクセルで十分だったようです。
もちろん、このような形を作ったからといって、最後の用語の整理が不要になるわけではありません。山崎さんもだいぶご苦労なさったはずですが、やらないよ りはかなりましだったのではないでしょうか。また、この用語集データはそのまま、索引原稿や、地図中の地名データの置換ファイルとして利用できましたの で、労力をかけた価値は十分にありました。
進行管理
企業向けのプロジェクト管理システムは優れたソフトがいくつもありますが、この点でもやはりwikiサイトを利用して、お金を使わずに工夫してみました。 編集プロダクションの担当者にもサイトにアクセスしてもらって、進行表を共有したのです。wikiの特徴として、それぞれが自分の作業を進めたら自分で進 行表を更新することができるため、リアルタイムで状況を反映させられるのです。とくに今回の本は国際共同印刷ということで、図版に合わせて文字数を刈り揃 える（いったん訳文をページに流し込んでみてから、はみ出した箇所や足りない箇所の文章を調整していく）必要があり、作業段階がふつうより多く、しかも進 行段階が節ごとにばらばらという状況になりましたので、細かい進行を逐一把握するために、このような仕組みは不可欠でした。
翻訳の各メンバーも、ＭＬに他の人の納品原稿が流れますので、いちおう全体の進行がわかります。（ウェブサイトは、メンバーのみしか閲覧できないとはい え、セキュリティ上の不安もあり、原稿や訳稿を直接ここにアップロードするのは控えました。その代わり訳稿はＭＬに流し、たとえば前回紹介したような翻訳 者と山崎さんのやり取りを他のメンバーも参照できる形にしました。）
こうして、ウェブサイトとメールでいちおうの用は足せるのですが、やはりデッドラインが見えてくると、いろいろ細かく話し合わなければならない部分が出て きます。そこで、山崎さんとプロダクションの編集者と私とで月に一度、定期的にSkype（スカイプ）による会議を行うことにしました。山崎さんが東京、 プロダクションは京都、私は西宮（兵庫）ですので、なかなか直接顔を合わせるわけにいきません。しかしSkypeならお金もかかりませんし、しかも電話と 違って3人以上で一緒に話せます。両手が空くのも便利です。この定例会議で進行を確認し、問題点を話し合って解決していきました。実際、このSkype会 議を定期的にしていなかったら、最後、間に合わなかったと思います。
今後のために
なんだか自慢話のようになってきましたが、けっしてすべてが思い通りにいったわけではありません。プロジェクトそのものは、いちおう予定通りに出版にこぎ つけましたし、まずまずうまくいったと言うべきでしょうが、方法の工夫としてはけっして満足のいくものではありませんでした。前回も書きましたが、私の理 想は翻訳メンバーが相互的な関係を作ることでした。ＭＬも、wikiサイトも、お互いに情報を出し合えるというということを考えて採用したのですが、結局 この利点を活用したのは山崎さんと私の二人だけで、これなら普通のメールとホームページ型の一方通行のサイトだけで十分だったわけです。
用語集の作り方にしても、たしかにエクセルのようなスプレッドシートにしておくのが汎用的でいいんですが、入力や検索はさらに工夫できたと思います。固有 名詞以外の用語、とくに一般語との境目にあるような言葉の訳し方の例を、もっとたくさん参照できるようにしたかったという思いもあります。また、最初、原 文の電子データが入手できなかったため、原文と訳文を対照した検索用データを蓄積していくことができませんでした。しかし、OCRを使ってでもやったほう がよかったかもしれません（コストを考えると、断言はできませんが）。
仕組みの工夫は、あくまでもチームメンバーの余計な負担を減らし、内容そのものの理解に力を注げるようにして、最終的に翻訳の質を高めることが目的です。 翻訳が楽になって、やっつけ仕事でできてしまうというのでは本末転倒です。実際、訳語の統一であれこれ調べているうちに背景知識が身につくということもあ るわけで、そのあたりを考えに入れた仕組みの工夫の余地は、まだまだあると思います。
自分で満足のいっていないやり方をここまでこまごまと書いてきましたのは、これからこういったプロジェクトをなさる翻訳者や編集者の方に参考にしていただ き、さらによい方法を編み出していただくためです。そして、できれば、今度こそ「相互的に」フィードバックを頂戴できれば幸いです。
